method and apparatus for packet transmission supporting unloading and continuous transmission

专利摘要:
method and apparatus for transmitting packets supporting unloading and continuous transmission; a method and apparatus for generating and processing transport packets. a method of generating a transport package by a shipping entity includes generating a transport package to include a package header, a payload header and a payload, the package header comprising an identifier of a payload type in a field indicating one of a plurality of types of payload, the plurality of types of payload comprising a first type of payload in a discharge mode, and a second type of payload in a continuous transmission mode, and sending the transport package.
公开号:BR112016001661A2
申请号:R112016001661-0
申请日:2014-07-25
公开日:2020-08-25
发明作者:Young-Kwon Lim；Imed Bouazizi
申请人:Samsung Electronics Co., Ltd.；
IPC主号:

专利说明:

[001] [001] This application generally refers to the transmission of media data and, more specifically, to a packet transmission protocol that supports both downloading and streaming. BACKGROUND ART
[002] [002] Moving Image Experts Group (MPEG) (MMT) media transport is a standard or digital container format that specifies technologies for delivering encoded media data for multimedia service over IP network environments ( Internet Protocol) heterogeneous. The encoded media data delivered includes both audiovisual media data that requires synchronized decoding and presentation of a specific unit of data at a designated time, namely timed data, and other types of data that are decoded and presented at an arbitrary time based on the context of service or user interaction, that is, non-timed data.
[003] [003] A new packaging mode, a Generic File Delivery (GFD) mode, has been introduced for the MMT delivery function. However, the integration of this mode in MMTP and with existing payload modes has not been optimized.
[004] [004] Therefore, there is a need for better devices and methods for the transmission of media data.
[005] [005] Modalities of the present invention provide a method and apparatus for generating and processing transport packets using a packet transmission protocol capable of supporting offloading and continuous transmission. Solution To The Problem
[006] [006] In an exemplary mode, a method of generating a transport package by a shipping entity is provided. The method includes generating a transport package to include a package header, a payload header and a payload, the package header comprising a payload type identifier in a field indicating one of a plurality of payload types payload, the plurality of payload types comprising a first payload type of a discharge mode and a second payload type of a continuous transmission mode; and send the shipping package.
[007] [007] In another exemplary mode, a device in a shipping entity capable of generating a transport package is provided. The apparatus includes a processing circuit configured to generate a transport package to include a package header, a payload header and a payload, the package header comprising a payload type identifier in a field indicating one of a plurality of types of payload, and plurality of types of payload comprising a first type of payload in an unloading mode, and a second type of payload in a continuous transmission mode; and a transmitter configured to send the transport package.
[008] [008] In yet another exemplary embodiment, a method of processing a transport package by a receiving entity is provided. The method comprises receiving a transport package to include a package header, a payload header and a payload, the package header comprising an identifier of a payload type in a field indicating one of a plurality of payload types payload, and the plurality of payload types comprising a first payload type in a discharge mode and a second payload type in a continuous transmission mode; and processing the payload according to the package header and the payload header.
[009] [009] In yet another exemplary embodiment, a device in a receiving entity capable of processing a transport package is provided. The apparatus comprises a receiver configured to receive the transport packet to include a packet header, a payload header and a payload, the packet header comprising an identifier of a payload type in a field indicating one of a plurality types of payload, and the plurality of types of payload comprising a first type of payload in a discharge mode, and a second type of payload in a continuous transmission mode, and the processing circuit configured to process the load according to the package header and the payload header.
[010] [010] Before starting the detailed description below, it may be advantageous to state definitions of certain terms and phrases used throughout this patent document: the terms "includes" and "comprises", as well as their derivatives, mean inclusion without limitation; the term "or" is inclusive, meaning and / or; the phrases "associated with" and "associated with it", as well as their derivatives, can mean inclusion, being included within, interconnecting with, containing, being contained, connecting to or with, engaging with or with, being communicable with, cooperating with, intercalate, juxtapose, be close to, be linked to or with, have, have a property of, or similar; and the term "controller" means any device, system or part thereof, which controls at least one operation, such a device may be implemented in hardware, firmware or software, or a combination of at least two of them. It should be noted that the functionality associated with any particular controller can be centralized or distributed, either locally or remotely. Definitions for certain words and phrases that are provided throughout this patent document, ordinary persons skilled in the art should understand that in many, if not most cases, these definitions apply to past as well as future uses of such words or defined phrases. BRIEF DESCRIPTION OF THE DRAWINGS
[011] [011] For a more complete understanding of the present disclosure and its advantages, reference is now made to the following description taken in conjunction with the accompanying drawings, in which equal reference numbers represent similar parts: Figure 1 illustrates an example of a system transmission in which various embodiments of the present invention can be implemented; Figure 2 illustrates an MMT package and the logical structure of the MMT package according to various embodiments of the present invention;
[012] [012] Figures 1 to 15, discussed below, and the various modalities used to describe the principles of the present disclosure in this patent document are for illustration only, and should not be construed in any way to limit the scope of the disclosure. Those skilled in the art will understand that the principles of the present invention can be implemented in any suitably arranged system or device.
[013] [013] MMT encoding and media delivery are discussed in the following document and description of standards: MPEG-H systems, ISO / IEC text 2nd CD 23008-1 MPEG Media Transport, which is incorporated here in this description as if fully stated here. MMT defines three functional areas including encapsulation, delivery and signaling. The functional area of encapsulation defines the logical structure of media content, the MMT package, and the format data units to be processed by an MMT-compliant entity. Specific MMT package, components including media content and the relationship between media content to provide information needed for adaptive delivery. The format of the data units is defined to encapsulate the encoded media to be stored OR transported as a payload of a delivery protocol, and to be easily converted between storage and transport. The functional delivery area defines the application layer protocol and payload format. The application layer protocol provides advanced features, including multiplexing, for delivery of the MMT package compared to conventional application layer protocols for multimedia delivery. The payload format is defined to carry encoded media data that is agnostic for the specific media type or encoding method. The functional signaling area defines the format of the messages to control delivery and consumption of MMT packages. Consumption management messages are used to signal the MMT package structure and delivery management messages are used to signal the payload format structure and protocol configuration.
[014] [014] MMT defines a new framework for delivering continuous multimedia over time, such as audio, video and other static content, such as widgets, files, etc. MMT specifies a protocol (ie MMTP) for delivering an MMT packet to a receiving entity. MMTP signals transmission time of the MMTP packet as part of the protocol header. This time allows the receiving entity to remove instabilities by examining the transmission time and reception time of each incoming MMT packet.
[015] [015] Modalities of the present disclosure recognize that a new packaging mode, the GFD mode, has been introduced for the MMT delivery function. GFD allows the transmission of any generic file. Modalities of the present disclosure recognize that MMT currently defines 4 other packaging modes: the media processing unit (MPU) mode, the MPU fragment mode, signaling message mode and early error correction (FEC) mode. The MPU mode provides a complete MPU and leaves fragmentation for the transport layer. The MPU Fragment mode is optimized for MPU delivery and packaging is done in a media-aware way, informing the customer receiving about the MPU fragment type and characteristics. The FEC and signaling modes are for delivering FEC repair packages and signaling messages, respectively. The FEC repair package carries a segmented set of FEC repair flow that can be used to recover one or more lost source packages.
[016] [016] Modalities of the present invention recognize that the MPU mode can be seen as a sub-process of the GFD mode, since the entire MPU is delivered as an object and without any media aware packaging. Information about the MPU can be fully delivered as part of the object's metadata in GFD mode. Consequently, embodiments of the present invention provide to remove the MPU mode and rename the MPU Fragment mode to the MPU mode to remove ambiguity. As a result, an MPU can be delivered either as a generic object using the GFD mode or as a set of independent fragments using this MPU mode.
[017] [017] Modalities of the present invention recognize that at present the payload format of a package is divided into several layers. A main payload header is required for each payload format and has a one-to-one mapping for the MMTP protocol header. Modalities of the present invention recognize to merge this generic payload header with the MMTP protocol header and make the remaining payload headers dependent on the type of payload. For example, fragmentation and aggregation are also dependent on the type of payload, as some types of payload, for example, FEC and GFD, do not require aggregation and fragmentation. Modalities of the present invention further provide a type of payload for signaling messages that allows easy identification of signaling messages and updates. The payload format will also allow the aggregation and fragmentation of signaling messages.
[018] [018] Figure 1 illustrates an example of a transmission system 100, in which various embodiments of the present invention can be implemented. In the illustrated embodiment, the wireless system 100 includes a sending entity 101, a network 105, receiving entities, 1100-116, wireless transmission points (for example, an Evolved Node B (eNB), node B), such as such as base station (BS) 102, base station (BS) 103, and other similar base stations or relay stations (not shown). Sending entity 101 is in communication with base station 102 and base station 103 over network 105 which can be, for example, the Internet, a media broadcast network, or IP-based communication system. Receiving entities 1110-116 are in communication with sending entity 101 via network 105 and / or base stations 102 and 103. For example, receiving entities 110-116 can receive media data for downloading and streaming from the entity sending 101. In various embodiments, sending entity 101 can generate and send MMTP packets and one or more of the receiving entities 110-116 can receive and process MMTP packets in accordance with the teachings of the present disclosure.
[019] [019] Base station 102 provides wireless access (via base station 101) to network 105 for a first plurality of receiving entities (for example, user equipment, mobile phone, mobile station, subscriber station) in the coverage area 120 from base station 102. The first plurality of receiving entities includes “user equipment 111, which may be located in a small company (SB); user equipment 112, which can be located in a company (E); user equipment 113, which can be located at a WiFi access point (SH); user equipment 114, which can be located in a first home (R) user equipment 115, which can be located in a second home (R); and user equipment 116, which may be a mobile device (M), such as a cell phone, a wireless communication laptop, a wireless enabled PDA, a tablet computer, or the like.
[020] [020] Base station 103 provides wireless access to network 105 for a second plurality of user equipment in coverage area 125 of base station 103. The second plurality of user equipment includes user equipment 115 and user equipment 116. In an exemplary embodiment, base stations 101-103 can communicate with each other and with user equipment 111-116 using OFDM or OFDMA techniques.
[021] [021] Although only six user devices are represented in Figure l1, it should be understood that system 100 can provide wireless broadband and network access to additional user devices. Note that user equipment 115 and user equipment 116 are located at the edges of both coverage area 120 and coverage area and 125. User equipment 115 and user equipment 116 each communicate with both base station 102 and station base 103 and can be considered to operate in the transfer mode, as is known to those skilled in the art.
[022] [022] User equipment 111-116 can access data from voice media, data, video, video conferencing, and / or other services over the network 105. In an exemplary embodiment, one or more of user equipment 111-116 can be associated with a WiFi WLAN access point (AP). User equipment 116 can be any of a number of mobile devices, including a wireless enabled laptop computer, personal data assistant, notebook, handheld device, or other wireless enabled device. User equipment 114 and 115 can be, for example, a personal wireless enabled computer (PC), laptop, gateway, or other device.
[023] [023] Figure 2 illustrates an MMT 200 package and the logical structure of the MMT 200 package according to various embodiments of the present invention. As illustrated, the MMT 200 package includes presentation of one or more information documents 205 and one or more assets 210 that may have associated transport characteristics 215. An asset 210 is a collection of one or more media processing units (MPU ) 220 that share the same asset identification (ID). An asset 210 includes encoded media data such as audio or video, or a website. The media data can be timed or non-timed.
[024] [024] Presentation information (PI) 205 documents include information specifying the spatial and temporal relationship between assets 210 for consumption. The combination of Hypertext Markup Language (HTML) and composition information (CI) documents are examples of PI 205 documents. A PI 205 document can also be used to determine an asset delivery order 210 in a package
[025] [025] An asset 210 is any multimedia data to be used to build a multimedia presentation. As discussed above, an asset 210 is a logical grouping of MPUS that share the same asset identification for transporting encoded media data. Encoded media data for an asset 210 can be either timed data or non-timed data. Timed data is encoded media data that has an inherent timeline and may require decoding and synchronized presentation of the data units at a designated time. Non-timed data are other types of data that can be decoded at an arbitrary time based on the context of a service or user input.
[026] [026] 220 MPUs of a single asset 210 have either timed or non-timed media. Two MPUs 220 of the same asset 210 carrying timed media data can have any overlap in their presentation time. In the absence of a presentation indication, MPUs 220 of the same asset 210 can be played in sequence according to their sequence numbers. Any type of media data that can be consumed individually by the submission mechanism of an MMT receiving entity can be considered as an individual asset 210. Examples of types of media data that can be considered as an individual asset 210 are types of data from audio media, video, or a web page.
[027] [027] An MPU 220 is a media data item that can be processed by an MMT entity and consumed by a presentation mechanism independently of other 220 MPUs. Processing an MPU 220 by an MMT entity includes encapsulation / de-encapsulation and packaging / unpacking. Consumption of a 220 MPU includes media processing (for example, encoding / decoding) and presentation. For packaging purposes, an MPU 220 can be fragmented into data units that can be smaller than an access unit (AU). The syntax and semantics of the MPU are not dependent on the type of media data carried in the MPU.
[028] [028] An MPU 220 may include a portion of data formatted according to other standards, for example, MPEG-4 (AVC) advanced video encoding or MPEG-2 (TS) transport stream. For any asset with asset identification (asset id) 'X' that depends on an asset with asset id 'Y', the m-th MPU of the asset with asset id 'X' and the N-th MPU of the asset with asset id 'Y' are not overlapping whenever 'm' is not equal to 'n', (ie, no sample in the m-th Asset MPU with asset id 'X' is within the time range defined by the sample boundaries of N-th MPU of Asset with asset id 'Y'. In addition, if the segment index box ('sidx') is present, the media ranges defined by the 'sidx' box are not overlapping, (that is, none sample media in the k-th media range (defined by the 'sidx' box) in an MPU is within the time range defined by the sample boundaries of the j-th media time range (defined by the 'sidx' box) for 'j3' different from 'k' In the absence of a 'sidx' box, the concatenation of the j-th MPU of the asset MPU with asset id 'Y' with the j-th MPU of the asset with asset id 'X 'without MP metadata U, results in a valid MPU. When a 'sidx' box is present the concatenation of the k-th media range (defined by the 'sidx' box) of the j-th asset MPU with asset id 'Y' with the k-th media range (defined by the box 'sidx') of the j-th asset MPU with asset id 'X' following the MPU metadata with asset id
[029] [029] A single MPU includes a full number of AUs or non-timed data. In other words, for timed data, a single AU is not fragmented into multiple MPUs. For non-timed data, a single MPU includes one or more items of non-timed data to be consumed by the submission engine. An MPU is identified by an associated asset id and a sequence number.
[030] [030] An MPU that includes timed media includes at least one streaming access point (SAP) as defined in annex I of ISO / IEC 14496-12, which is incorporated by reference. The first access unit of an MPU is an SAP for processing by an MMT entity. For timed media, this implies that the order of decoding the first AU in the MPU payload is 'O0'. For the MPU including data formatted according to other standards, the MPU payload starts with the information needed to process that format. For example, if an MPU includes video data, the MPU payload includes one or more groups of images and the decoder configuration information needed to process them. In another example, if an MPU includes MPEG-2 TS packages, the MPU payload can start with TS packages including program association table (PAT) program map table (PMT) for the remaining TS packages or subsequent For timed media data, the duration of the presentation, the decoding order, and the presentation order of each AU are flagged as part of the MPU metadata. The MPU does not have an initial presentation time. The presentation time of the first AU in an MPU is described by the PI document. The PI document includes information specifying the initial presentation time for each MPU.
[031] [031] Figure 3 illustrates an example of timing provided by a PI document for presenting MPUs from different assets, according to an illustrative embodiment of the present disclosure. In this illustrative example, the specific PI document that the MMT receiving entity will present MPU * 1 of Asset * 1 and Asset t 2 simultaneously. At a later time, MPU * 1 of Active À 3 is scheduled to be presented. Finally, MPU À 2 of Active À 1 and Active * 2 must be presented in synchronization. The presentation time specified for an MPU defines the presentation time of the first AU of this MPU. An MPU that contains non-timed media data may designate a data item as the entry point.
[032] [032] MFUS enable media aware fragmentation of an MPU for transport purposes. This allows a sending MMT entity to fragment MPUs taking into account consumption at the receiving end. An MFU includes a media data unit, which can be smaller than an AU for timed media data, and the included media data can be processed by the media decoder. An MFU includes an MFU header that includes information about the boundaries of the transported media data. The syntax and semantics of the MFU are independent of the type of media data carried in the MFU. If the size of an MFU is larger than the size of a link layer frame, an MFU can be fragmented into multiple link layer frames. An MFU includes an identifier to distinguish one MFU from another in the same MPU as well as relationship information between MFUs within a single AU in a way that is agnostic for the encoded media format. The dependency relationship between MFUs in a single AU is described as well as the relative priorities of the MFUs. The information can be used by underlying delivery layers for improved delivery. For example, the delivery layer may skip delivery of disposable MFUs to support QoS in certain circumstances, for example, insufficient bandwidth on some network links.
[033] [033] According to the various modalities of the present invention, an MMT payload is a generic payload used to package and transport assets, generic objects, and other information for consumption in an MMT package using the MMT protocol (MMTP ). The MMT payload can be used to package MPUs, generic objects, and signaling messages. The MMT payload can carry one or more fragments of MPUs, one or more signaling messages, one or more generic objects (including complete MPUs), one or more repair symbols, etc. The type of payload is indicated by the type field (or object type) in the MMTP packet header, as will be discussed in more detail with the discussion in Figure 9 below. For each type of payload, a single data unit for delivery, as well as a specific payload header type, is defined. For example, a fragment of an MPU (for example, an MFU) is considered to be a single unit of data when MMT payload carries fragments of MPU. The MMT protocol can aggregate multiple data units with the same data type in a single payload. You can also fragment a single data unit into multiple packets.
[034] [034] The MMT payload consists of a payload header and payload data. Some types of data may allow fragmentation and aggregation, in which case, a single data unit is divided into several fragments or a set of data units is delivered in a single package. Each data unit can have its own payload header depending on the type of payload. For types that do not require a specific payload type header, no payload type header is present and the payload data follows the MMTP header. Some fields in the MMTP packet are interpreted differently based on the type of payload. The semantics of these fields are defined by the type of payload in use.
[035] [035] Figure 4 illustrates an exemplary structure of a continuous transmission mode payload header 400 according to various embodiments of the present invention.
[036] [036] The delivery of MPUs to MMT receivers using the MMT protocol requires a packaging and unpacking process to take place at the sender and receiver, respectively, to allow for the delivery of large MPUs. The MPU delivery mode considers a complete MPU or specific subparts of a single MPU as independent delivery data units for packaging or aggregation to facilitate wide variations in MPU size. The MMTP payload format streaming mode (for example, the MPU mode)
[037] [037] In the 0x00 payload type, the MPU is fragmented in a media-aware manner allowing the transport layer to identify the nature and priority of the fragment that is transported. A fragment of an MPU can be, for example, MPU metadata, or a film fragment metadata, an MFU, or an untimed data item. This continuous transmission mode is also used to deliver signaling messages or recovery symbols.
[038] [038] In this exemplary modality, semantics and payload header length 400 of continuous stream mode 400 of each payload header field of continuous stream mode 400 are provided as follows: field length 402 has a length of 16 bits and this field indicates the size of the entire payload including this field; the DU data type 404 field can be 5 bits long and can indicate the payload delivery data unit type, for example, as provided by table 1 below. [Table 1] a single complete MPU as a complete 0 MPU single delivery data unit The ftyp, mmpu and moov boxes as well as any other boxes that appear in the middle as a single delivery data MPU 1 metadata unit - no header of delivery data unit is used The moof box and the mdat box, excluding all media data within the mdat box as a 2 film fragment metadata single delivery data unit.
[039] [039] Continuing with continuous stream mode payload header 400 fields, the aggregation flag (A) 406 field can be a bit long and when set to '1' indicates that more than one unit of delivery data it is present in the payload that the fi 408 field is ignored; the fragmentation indicator field (£ i) 408 may be 2 bits long and may indicate that the fragmentation indicator contains information about fragmentation of the data unit into the payload, for example, as illustrated in Table 2 below. [Table 2] Payload contains one or more delivery data unit headers and complete delivery data units. Payload contains the delivery data unit header and the first one. delivery data unit fragment Payload contains a delivery data unit fragment that is "neither the first nor the last part.
[040] [040] The value of this field 408 can be set to '00' when the value of field "A" is set to '1'.
[041] [041] Continuing with the payload header fields of continuous transmission mode 400, the counter field (counter) 410 can be 16 bits, indicating a payload number containing fragments of the same delivery data unit following this load MMT usable if the aggregation flag is set to '0', and indicates the number of delivery data units aggregated in this payload if the aggregation flag is set to '1'. The DU length field 412 can be 16 bits long and the field indicates the The length of the data following this field 412. When the aggregation flag is set to '0', this field 412 may not be present. When aggregation flag is set to '1', this field 412 can appear as many times the value of the "counter" field 410 and before each aggregated data unit. The DU Header 414 field is the data unit header, which depends on the type of delivery data unit, as will be discussed in more detail below. When aggregation flag is set to '1', this field 414 can appear as the value of the field "counter" 410 and previous to each unit of aggregate delivery data many times. When aggregation flag is set to '0', this field 414 can appear when the value of field 'f i' 408 is 'O01'.
[042] [042] Figure 5 illustrates an exemplary structure of a timed media MFU header 500 according to various embodiments of the present invention. The timed media MFU header 500 is an example of a delivery data unit header, as included in DU header 414 in Figure 4, for timed media data.
[043] [043] In this exemplary embodiment, the semantics and length of each timed media MFU header field 500 are provided as follows: the movie fragment sequence number 502 field can be 32 bits long and includes the movie fragment sequence number to which the media data of this MFU belongs; the sample number 504 field can be 32 bits long and includes the sample number of the sample for which the MFU media data; The offset field 506 can be 16 bits long and includes the offset of the media data from this MFU within the referenced sample; the subsample priority 508 field can be 8 bits long and provides the priority of the media data carried by this MFU compared to other media data from the same MPU. For example, the subsample priority value can be between 0 and 455, with higher values indicating higher priority. In addition, the dependency counter 510 field can be 8 bits long and indicates the number of data units that depend on their media processing through the media data in this MFU.
[044] [044] Figure 6 illustrates an exemplary structure of an untimed MFU header 600 according to various embodiments of the present invention. The non-timed MFU header 600 is an example of a delivery data unit header, as included in DU header 414 in Figure 4, for non-timed media data.
[045] [045] In this exemplary modality, the semantics and length of each field of the 600 non-timed MFU header are provided as follows: the item id field
[046] [046] Figure 7 illustrates an exemplary structure for a signaling message header 700, in accordance with various embodiments of the present invention. Signaling message header 700 is an example of a delivery data unit header, as included in DU header 414 in Figure 4, for a signaling message.
[047] [047] In this exemplary modality, the semantics and length of each signaling message header field 700 are provided as follows: the message id 702 field can be 16 bits long and indicates the type of signaling message; The version field can be 8 bits long and indicates the version number of the signaling message; The reserved field (RES) can be 8 bits long and is reserved for future use and can be set to O.
[048] [048] MMTP also supports the transport of generic and active files and uses payload type 1. A generic asset consists of one or more files that are grouped logically and that share something in common for an application, for example, Segments of a Dynamic Adaptive Streaming over HTTP Representation (DASH), a sequence of MPUs, etc.
[049] [049] In the GFD payload type mode, a generic asset is delivered through MMTP using the GFD payload type. GFD requires a GFD session description discussed below to describe the delivery characteristics and generic asset content. Modalities of the present invention provide the establishment of GFD session through the MMTP protocol. When delivered within MMTP, the GFD session can be mapped into exactly one packet id flow.
[050] [050] Each file delivered within a GFD session requires association of transport delivery information. This includes, but is not limited to, information such as transfer length. Each file delivered within a GFD session can also have specific content parameters associated with it, such as file name, identification and / or location, media type, file size, file encoding or file message synthesis. In line with HTTP / 1.1 protocol as defined in IETF RFC 2616, which is incorporated by reference, each file within a generic asset may have assigned any metadata about the body entity, that is, the file delivered. Additional details of the GFD operation discussed below. Files sent in a GFD session may have to be made available to an application, for example, through a proxy cache or by other means. Each object is then delivered through the GFD session.
[051] [051] Before a receiver can establish a GFD session, the receiver may need to obtain sufficient information, such as session access information and GFD session information. The session access information for the GFD session, when operating in MMT, is defined in 23008-1, which has been incorporated by reference. The GFD session information is described in more detail below. The GFD Session Description could be in a form such as the Session Description Protocol (SDP) as defined in RFC4566, XML metadata as defined in RFC3023, or HTTP / MIME headers as defined in RFC 2616, etc., each those RFC standards documents are expressly incorporated herein by reference.
[052] [052] GFD Session Information: the GFD protocol delivers files. In GFD mode, each file is assigned a Transmission Object Identifier (TOI) parameter and a code point (CP) parameter. The TOI parameter provides which object is associated with a unique identifier within a GFD session. Each object is associated with a code point. A code point summarizes object and specific object delivery properties. Packets with the same TOI can have the same value at the code point.
[053] [053] The GFD table provides a list of code points. Each code point is dynamically assigned a code point value. The semantics of the GFD Table is provided in Table 3 below.
[054] [054] A code point can include the maximum transfer length of any object delivered with this code point signal. In addition, a code point can include any of the following information: the actual transfer length of the objects, any information that may be present in the header entity as defined in RFC2616, section 7.1, incorporated by reference, a content-location- model as described below using the packet id TOI parameter and, if present; and specific information about the content, for example, how the content is packaged, etc. TOI and packet id can be used to generate Content-Location for each TOI and packet id. If such a model is present, the processing as described below in relation to the content-location-model can be used to generate The content-location and the URI value can be treated as the content-location field in the header entity. Within a session, a maximum of 256 code points can be defined. The definition of code points can be dynamically configured in the GFD Session Description. An example of the semantics for the code point is provided in Table 4 below. [Table 4] Element or Attribute Name = CodePoint GFD Session Defines the code point value in the GFD session as provided in the CP value of the header of the Qvalue M GFD package. The value can be between 1 and 455. The value 0 is reserved, specifies the maximum transfer length in bytes of (QmaximumTransferLength M any object delivered with this code point in this GFD session.
[055] [055] A code point can include a BcontentLocationTemplate attribute. the BcontentLocationTemplate attribute value can contain one or more of the identifiers listed in Table 5 below. At each URL, the identifiers in Table 5 can be replaced by the substitution parameter defined in Table 5. Identifier matching is case sensitive. If the URL contains unescaped $ symbols ("unescaped") that do not involve a valid identifier, then the result of the URL formation is undefined. The format of the identifier is also specified in Table 5 below.
[056] [056] Each identifier can have a suffix, within the characters "just involving following this prototype:"% O0 [width] d ". The parameter" width "is an integer without sign that provides the minimum number of characters to be printed. If the value to be printed is shorter than this number, the result can be padded with zeros, the value may not be truncated even if the result is greater. The BcontentLocationTemplate can be created in such a way that the application of the substitution process results in valid URLs. External string identifiers can only contain characters that are permitted within URLs in accordance with RFC 3986, incorporated herein by reference.
[057] [057] GFD operation: MMTP's GFD mode delivers regular files. When delivering regular files, the object represents a file. If the code point defined in the GFD Session description contains entity-header fields or entity-header fields that can be generated, then all of these entity-header fields can apply to the delivered file.
[058] [058] Figure 8 illustrates an exemplary structure for a GFD 800 mode package structure according to various embodiments of the present invention. Payload 800 packets sent using MMTP may include a GFD 802 to 818 payload header and a GFD 820 payload, as shown in Figure 8. In some particular cases, the GFD sender may need to produce packets that do not contain any payload. This may be required, for example, to signal the end of a session. The payload header of GFD 802 to 818 has a variable size. In the payload header of GFD 802 to 818, all the entire fields are transported in "big-endian" or "network order" format, that is, the most significant byte (octet) in the first place. Bits designated as "padding" or "reserved" (r) are set to 0 by senders and ignored by receivers. Unless otherwise stated, numerical constants in these examples are in decimal form (base 10).
[059] [059] In this exemplary embodiment, the semantics and length of each field of the GFD 800 mode packet structure are provided as follows: the field of length 802 includes 16 bits and indicates the size of the entire payload including this field; the S 804 field can be one bit long and indicates the number of 32-bit integer words in the TOI field (the TOI field has 32 * S + 16 * H bits in the 802 length field, for example, The length is or O bits, 16 bits, 32 bits or 48 bits); the H 806 field can be 1 bit long and allows the TOI field lengths to be multiples of a half word (16 bits), while ensuring that the aggregate length of the start offset and TOI fields is a multiple of 32 bits; the L 808 field can be a bit long and indicates whether this is the last packet delivered for that object; the B 810 field can be a bit long, and indicates whether this packet contains the last byte of the object; the code point (CP) field 812 can be 8 bits long and includes an opaque identifier which is transmitted to the packet payload decoder to carry information on the packet payload. The mapping between the code point and the actual codec is defined on a per-session basis and communicated out of band as part of the session description information. The object metadata (M) field 814 can be a bit long and this flag indicates whether the object metadata provided as part of the payload or not. When set to 1, the payload is a MIME entity, where the header can contain at least the content type and the content-location headers. The reserved field (RES) can be 3 bits long and is set to 0; the start offset field 818 (16 + 32 * O + 16 * H) indicates the location of the current payload data on the object; and the GFD 820 payload field includes the GFD payload.
[060] [060] The object identifier can be defined as a unique identifier of the generic object being delivered. The mapping between the object identifier and the object information (such as URL and MIME type) can be done explicitly or implicitly. For example, a sequence of DASH segments can use theThe segment index as the object identifier and a numeric representation identifier as the packet id. This mapping can also be performed using a signaling message.
[061] [061] For the payload of GFD 820, the bytes of the object are referenced so that byte O is the beginning of the object and byte T-1 is the last byte of the object with T the transfer length of the object. The data carried in the payload of an MMTP packet can consist of a consecutive portion of the object starting at the beginning of byte X and ending at the beginning of byte X + Y where X is the value of the start offset field in the GFD packet header. and Y is the length of the payload in bytes. Y may not be carried in the packet, but framing may be provided by the underlying transport protocol.
[062] [062] The MMT protocol (MMTP) is an application layer transport protocol designed to efficiently and reliably deliver MMT packets. MMTP can be used to deliver both timed and non-timed media data. It supports several features, such as media multiplexing, network instability calculation, which are essential to provide content composed of various types of encoded media data. MMTP can run over existing protocols, for example, User Datagram Protocol (UDP) and IP. In the present description, a specific transport of the formatted data other than the MMT payload format as required. A single MMTP packet can carry exactly one MMT payload. MMTP assumes that the sending entity performs congestion control and, therefore, congestion control function is not specified in this specification. This is because MMTP runs on top of UDP / IP and will be used by a wide variety of applications, this function is left to implement sending entities.
[063] [063] MMTP supports the multiplexing of different assets over a single stream of MMT packets. MMTP delivers multiple types of data in order of consumption to the receiving entity to help synchronize between different types of media data without introducing a long delay or requiring a large buffer. MMTP also supports multiplexing of media data and signaling messages within a single packet stream. A single load of MMT can be carried in just one MMT package.
[064] [064] MMT protocol defines two packaging modes, GFD mode and MPU mode. The GFD mode (for example, unloading mode) defines a mode for packaging media data based on the size of the payload to be transported and the MPU mode (for example, the streaming mode) defines a mode for packaging media data based on the type of data to be carried in the payload. MMT protocol supports the mixed use of packets with two different modes in a single delivery session. A single packet stream of MMT packets can be arbitrarily composed of payloads with two types. MMTP provides the structure and definitions for calculating and removing instability introduced by the underlying delivery network, so that constant data flow delay can be achieved. Using the horodata field in the packet header, instability can be calculated accurately without requiring any additional information and signaling protocols.
[065] [065] Figure 9 illustrates an exemplary structure for an MMTP 900 package according to various embodiments of the present invention.
[066] [066] Continuing with the semantics and length of each field in the MMTP 900 packet, the FEC type (FEC) 906 field can be 2 bits long and indicates the type of FEC scheme used to protect MMT packets. An example of values and associated descriptions for this 906 field can be listed in Table 7 below.
[067] [067] Continuing with the semantics and length of each field in the MMTP 900 packet, the reserved field (RES) 908 can be 3 bits long and is reserved for future use; the packet counter flag (C) 910 field can be 1 bit long and a '1' indicates that the packet counter field is present; the RAP flag (R) 912 field can be a bit long and, when set to '1', indicates that the payload contains a random access point for the data flow of that data type, the extension flag ( X) 914 can be 1 bit long and a '1' indicates that the header extension field is present, the last (L) 916 field can be a bit long, and a '1' indicates that the last of the packets with the same value as the objet identifier field; the packet id 918 field can be 16 bits long and includes an integer value assigned to each asset to distinguish packages from one asset to another. Separate values are assigned to FEC signaling messages and repair flows. The packet id is unique across the delivery session timeline and for all MMT flows delivered by the same MMT shipping entity. The mapping between the packet id and the asset id is signaled by the MMT Package Table as part of a signaling message. For Application Layer - Early Error Correction (AL-FEC), the mapping between packet id and the FEC repair flow is provided in the AL-FEC message. The packet id is unique for all flows of MMT packages delivered by the same MMT sending entity.
[068] [068] Continuing with the semantics and length of each field in the MMTP 900 packet, the objet identifier 920 field can be 32 bits long and includes an identifier from the application layer object of the current load is extracted. The exact semantics and use of this 920 field may depend on the type of payload. The packet sequence number 922 field can be 32 bits long and includes an integer value that is delimited by the packet id and starts from an arbitrary value incremented by one for each MMT packet. This value returns to '0' after its maximum value is reached. The horodata field 924 can be 32 bits and specific to the MMT packet delivery time instance. NTP time is used in horodata as specified as the "short form" in clause 6 of IETF RFC5905, NTP version 4, which is incorporated by reference. This time specifies the time in the first bit of the MMT packet. The packet counter 926 field can be 32 bits long and includes an integer value to count the MMT packet. The value is increased by sending an MMT packet and is different from the packet id value. This field 926 starts from an arbitrary value incremented by one for each MMT packet sent. The value of field 926 returns to '0' after its maximum value.
[069] [069] The extension header 928 field includes user-defined information. The header extension mechanism is provided to allow proprietary extensions to the payload format to allow applications and media types that require additional information to be carried in the payload format header. The header extension mechanism is designed in such a way that it can be discarded without affecting the correct processing of the MMT payload. The extension header in field 928 can be in the form as illustrated in Figure 10, which illustrates an exemplary structure for header extension 1000 according to various embodiments of the present invention.
[070] [070] Continuing with the semantics and length of each field in the MMTP 900 packet, the payload data field 930 includes the payload data; and the 932 source FEC payload ID field can be 2 bits long and can be used only when the FEC type value is set to '1'. An MMT package with type of FEC = 1 can be used for AL-FEC protection and after AL-FEC protection this field can be added to the MMT package.
[071] [071] In these “illustrative modalities, the present invention provides a harmonized structure for MMTP with two layers allowing indication of specific parts of an MPU for fragmented delivery. As a first layer, the payload type (for example, discharge mode, continuous transmission mode, GPU mode, MPU mode, etc.) is signaled by the type field (or object type) in the MMTP header. Like the second layer, the delivery data unit type is signaled by the DU type field in the MPU mode payload header. Accordingly, the embodiments of the present invention provide a transmission protocol that supports both downloading and streaming in the same protocol by integrating GPU mode and MPU mode within MMTP.
[072] [072] Figure 11 illustrates an exemplary diagram 1100 of packaging timed media data, in accordance with various embodiments of the present invention. Packaging of an MPU containing timed media can be done in an MPU format aware and / or MPU format agnostic mode. In MPU format agnostic mode, MPU is packaged in data units of equal size (except for the last data unit, the size may be different), or a predefined size according to the MTU size of the network. underlying delivery using GFD. In other words, packaging the MPU format agnostic mode can only consider the size of the data to be carried in the packet. The type field for the MMTP packet header is set to 0x00 to indicate that packaging is the format agnostic mode.
[073] [073] In MPU format aware mode the packaging procedure takes into account the boundaries of different types of data in MPU to generate packets for using MPU mode. The resulting packets carry units of delivery data from either MPU metadata, film fragment metadata, or MFU. The resulting packages may not carry more than two different types of delivery data units. The MPU metadata delivery data unit is assigned the DU type 0x01. MPU metadata includes the 'ftyp' box (file type), the 'mmpu' box (an MPU), the 'moov' box (Movie), and any other boxes that are applied to the entire MPU. The 'ftyp box 'contains a file type, the' mmpu 'box contains an MPU configuration, and the' moov 'box contains codec configuration information.The film fragment metadata delivery data unit consists of the' moof box '(movie fragment) and the box header' mdat '(media data) (excluding any media data) and DU type 0x02 is assigned. The' mdat 'box contains media data and control information from the data media, and the 'moof' box contains header information for the media data.The media data, MFUS in MPU mdat box, is then divided into several units of MFU delivery data in a format-conscious way. This can, for example, be done with the help of the MMT hint strip. The MFU can include 1) media data only, 2) media data with a number sequence number, and 3) media data with some control information. Each MFU is attached to the MFU header, which has syntax and semantics. The MFU header is followed by the MFU media data.
[074] [074] Figure 12 illustrates an exemplary diagram 1200 for packaging non-timed media data, according to various embodiments of the present invention. packaging of non-timed media data can also be done in two different modes. In MPU format agnostic mode, the MPU is packaged in delivery data units of equal size (except for the last data unit, the size may be different) or a predefined size according to the MTU size of the underlying delivery network for using GFD mode. The MMTP packet type field is set to 0x00 to indicate that the packaging is generic. In format agnostic mode, the MPU is packaged in the package containing delivery data units of either the MPU or MFU metadata using the MPU mode. The MPU metadata contains the 'ftyp' box, the 'mMoov' box, the 'meta' box and any other boxes that are applied to the entire MPU. Each unit of MFU delivery data contains a single item of untimed media. Each item of non-timed data is then used to build an MFU. The MFU consists of an MFU header and non-timed MFU data.
[075] [075] The unpacking procedure is performed at the MMT receiver to obtain the transmitted MPU. (o) Unpacking procedure can operate in one of the following modes, depending on the application needs: an MPU mode, a fragment mode, and a media drive mode. In MPU mode, the payload remover regenerates the complete MPU before forwarding the MPU to the application. This mode is suitable for non-timed critical delivery, that is, the presentation time of the MPU as indicated by CI is sufficiently behind the delivery time of the MPU. In fragment mode, the payload remover regenerates a complete fragment, including fragment metadata and the 'mdat' box with media samples before forwarding it to the application. This mode does not apply to untimed media. This mode is suitable for delay-sensitive applications, where the delivery time budget is limited, but is large enough to recover a complete fragment. In media drive mode, The payload remover extracts and forwards media drives as quickly as possible to the application. This mode is applicable for very low delay media applications. In this mode, recovery of the MPU is not necessary. Processing of fragment media data is not necessary, but can be performed to resynchronize. This mode tolerates out-of-order delivery of fragment metadata, which can be generated after media units are generated. This mode applies to both timed and non-timed media.
[076] [076] Using MFU sequence numbers, receiver is able to detect missing packets and apply any error correction procedures, such as FEC or ARQ to recover missing packets. The type of payload can be used by the sender to determine the importance of the payload for the application and apply appropriate error resilience measures.
[077] [077] Each GFD delivery session can have a GFDT that is local to the given session. A file that is delivered in the GFD session, but not described in the GFDT is not considered a 'file' belonging to the GFD delivery session. An object that is received with an unmapped code point must be ignored by a GFD receiver.
[078] [078] The files in the GFD session may have to be provided to an application, for example, in a composition information document or a media presentation description, as defined in ISO / IEC 23009-l1, which is incorporated by reference, can refer to files delivered using MMTP as GFD objects. The file can be referenced using the URI provided or derived from content-location, either provided in-band or as part of the GFD session description. In certain cases, files have a time to start availability in the application. In this case, the GFD session can deliver the files in such a way that the last package of the object is provided in such a way that it is available later in the receiver at the time of availability start as announced in the application. Applications made available through the GFD mode may impose additional and more stringent requirements on sending files within a GFD session.
[079] [079] Within a session, the sender (for example, the sending entity 101) transmits a sequence of packets within the session. Several objects can be delivered in the same GFD session. If more than one object must be delivered within a session, then the sender can use the TOI field. In this scenario, each object can be identified by a unique TOI within the session, and the sender can use the corresponding TOI for all packages belonging to the same object. The mapping between TOIs and files carried in a session are described in the GFD session description as well as in the entity-header fields if entity mode delivery is applied.
[080] [080] The GFD header, as discussed above, can be used. The GFD packet header includes a code point field that can be used to communicate to a receiver for configurations for information that is established for the session and may even vary over the course of a session. The mapping between code point settings and values is communicated in the GFD session description.
[081] [081] For example, let T> O be the transfer length of any object in bytes, the data carried in the payload of a packet consists of a consecutive portion of the object. So, for any arbitrary X and any arbitrary Y> O, as long as X + Y is, at most, T a packet can be generated. Under these criteria, the following may contain: (a) the data carried in the payload of a packet may consist of a consecutive portion of the object starting from the beginning of byte X to the beginning of byte X + Y; (B) the start offset field in the GFD package header can be set to X and the payload data can be added to the package to send; and (C) if X + Y is identical to T, the packet header flag B can be set to 1, then the packet header flag B can be set to O.
[082] [082] The following example procedure can be used by a sender to deliver an object to generate packages containing start offset and corresponding payload data. First, the sender sets the byte shift counter X to 0. Then, for the next packets to be delivered set the length in bytes of a payload to a fixed value Y, which is a) reasonable for a payload useful packet (for example, ensuring that the total packet size does not exceed the MTU), b) such that the sum of X and Y represents at most T, and c) such that it is suitable for the data of payload included in the package. The sender then generates a packet according to the a-c rules from above. Then, if X + Y is equal to T, the sender sets the packet header flag B to 1, then the sender sets the packet header flag B to O, increments X = X + Y and returns to generate the package according to ac rules.
[083] [083] The package delivery order can be arbitrary, but the sender can deliver in the absence of other delivery restrictions with an increase in the start offset number. The transfer length may be unknown before sending previous pieces of data. In this situation, T can be determined later. However, this does not affect the submission process above. Additional packages can be sent according to the rules in (A) - (C) from above. In this situation, flag B can only be adjusted for the package containing the last portion of the object.
[084] [084] The GFD Session Description contains one or more code points identified by different code point values. After receiving each packet, the receiver (for example, one or more receiving entities 110-116) can proceed with the following steps. First, the receiver analyzes the packet header and verifies that it is a valid header. If it is not valid, then the package can be discarded without further processing. Second, theThe receiver analyzes the code point value and checks whether the GFD session description contains a corresponding code point. If it is not valid, then the package can be discarded without further processing. Third, the receiver processes the rest of the packet, which includes interpreting the other header fields appropriately and using source offset and payload data to reconstruct the corresponding object as follows: a) the receiver can determine from which object a received packet was generated by the session information, and if any, by the TOI carried in the payload header; b) after receiving the first packet for an object, the receiver uses the Maximum Transfer Length received as part of the Object Transmission Information to determine the maximum length T 'of the object; Cc) the receiver allocates space for the T 'bytes that the object can request; d) the receiver calculates the payload length, Y, by subtracting the packet header length from the total received packet length; e) the receiver allocates a RECEIVED Boolean matrix [O0..T'-1] with all T entries initialized to false to track received object symbols.
[085] [085] CodePoint GFD: information about the files delivered using the GFD mode is indicated in the MP Table if the asset scheme code is set to "GeneralFile". Generic objects that are delivered using GFD mode can be grouped together as an MMTP stream identified by the packet id. Packages that carry generic objects using GFD mode can be marked with type 1 in the MMTP package header type field. The GFD table defines one or more code points. The code point table can be provided in Table 8 below.
[086] [086] Although the various modalities described herein discuss MMT data communication, it should be noted that the various modalities of the present are not limited to MMT communications. For example, buffer size and fixed delay determinations can be applied to any suitable type of delivery of media or data content and / or any suitable type of transmission system in accordance with the principles of the present invention.
[087] [087] Figure 13 illustrates a process for processing a transport package at a receiving entity in accordance with an illustrative embodiment of the present disclosure. For example, the process shown in Figure 13 can be performed by some or all of the receiving entities 110-116 in Figure 1. The process can also be implemented by the electronic device 1500 in Figure 15.
[088] [088] The process begins with the receiving entity receiving a transport package (step 1305). The receiving entity then identifies a type of payload from a field indicating the type of payload in the packet header (step 1310). For example, in step 1310, the receiving entity can analyze the packet header and identify the value in the object type field, such as field 904 in Figure 9, and identify the corresponding payload type according to the Table 6. If the payload type is the generic mode, the receiving entity processes the payload data in a generic way (step 1315).
[089] [089] If the payload type is continuous transmission mode, the receiving entity identifies a type of delivery data unit from a field indicating the type of delivery data unit in a payload header of continuous transmission mode (step 1320). For example, in step 1320, the receiving entity can identify the delivery data unit type of the DU data in the packet transport, as well as the payload data type of MMT.
[090] [090] For example, the receiving entity can analyze the payload header of continuous transmission mode, as illustrated in Figure 4, to identify the value in the DU type 404 field to identify the type of delivery data unit. according to Table 1. For example, DU data can include one of: a complete MPU, MPU metadata, film fragment metadata, a timed MFU, a non-timed MFU, a signaling message, or recovery symbols based on the value included in the DU type field.
[091] [091] Thereafter, the receiving entity identifies information on whether MFU (s) is present in the transport package from a fragmentation indicator field in the continuous stream mode payload header (step 1325). For example, in step 1325, the transport package includes one or more fragments of an MPU arranged as MFUs. The transport package can include a plurality of delivery data units, each delivery data unit including a DU header and DU data. The receiving entity can determine whether the DU data includes: one or more delivery data unit headers and complete delivery data units, a delivery data unit header and a first fragment of a delivery data unit , a fragment of the delivery data unit that is neither the first nor the last part, or a last fragment of the delivery data unit based on the value in the fragmentation indicator field according to Table 2.
[092] [092] The receiving entity then processes the DU data (step 1330). For example, at step 1330, the receiving entity can process the DU data according to the type of delivery data unit identified. The receiving entity can process and decode the DU data to display the media through a user interface for the user associated with the receiving entity.
[093] [093] Figure 14 illustrates a process for generating a transport package in a shipping entity according to an illustrative embodiment of the present disclosure. For example, the process represented in Figure 14 can be performed by the sending entity 101 in Figure 1. The process can also be performed by the electronic device 1500 in Figure 15.
[094] [094] The process begins with the sending entity generating a transport package (step 1405). For example, in step 1405, the sending entity can generate the packet to include data downloading or streaming. The sending entity may include a plurality of delivery data units with each delivery data unit including a DU header and DU data.
[095] [095] The shipping entity then includes a payload type identifier in a field indicating the payload type in a packet header for the transport packet (step 1410). For example, in step 1410, the sending entity can include a value corresponding to the type of object, as in Table 6, in a type field of the packet header, as in field 904 in Figure 9.
[096] [096] The sending entity then determines whether the payload type is a continuous transmission mode payload type (step 1415). If the payload type is a type other than continuous transmission mode, for example, generic mode (GFD), the sending entity then generates the transport package according to the payload time and proceed to step 1430 to send the generated transport packet.
[097] [097] If, however, the payload type is a continuous transmission mode payload type, the sending entity includes an identifier for a delivery data unit type in a field indicating the type of delivery unit. delivery data in a continuous stream mode payload header (step 1420). For example, in step 1420, the sending entity may include a value corresponding to the type of delivery data unit for the packet in a field in the continuous stream mode payload header, as illustrated by the DU type 404 field. of the continuous transmission mode payload header in Figure 4 according to Table 1 of delivery data unit types. For example, the DU type field may indicate that the DU data includes one of: a complete MPU, MPU metadata, film fragment metadata, a timed MFU, an untimed MFU, a signaling message, or symbols recovery based on the included value.
[098] [098] Thereafter, the sending entity includes an identifier of information on whether MFU (s) are present in the packet in a fragmentation indicator field in the continuous stream mode payload header (step 1425). For example, at step 1425, the transport package may include one or more fragments of an MPU arranged as MFUs. The sending entity may indicate that the DU data includes: one or more delivery data unit headers and complete delivery data units, a delivery data unit header and a first fragment of a delivery data unit , a fragment of the delivery data unit that is neither the first nor the last part, or a last fragment of the delivery data unit based on a value included in the fragmentation indicator field in accordance with Table 2.
[099] [099] The sending entity then sends the generated transport package (step 1430). For example, in step 1430, the sending entity can send the transport package to a receiving entity to receive and process the transport package, for example, according to the process illustrated in Figure 13.
[100] [100] Although figures 13 and 14 illustrate examples of processes for processing and generating transport packages by receiving and sending entities, respectively, several modifications can be made to Figures 13 and 14. For example, while shown as a series of steps , several steps in each Figure can overlap, occur in parallel, occur in a different order, or occur several times.
[101] [101] Figure 15 illustrates an example of electronic device 1500 in which various embodiments of the present invention can be implemented. In this example, electronic device 1500 includes a controller 1504, memory 1506, persistent storage 1508, a communications unit 1510, an input / output unit (1/0) 1512, and a screen 1514. In these illustrative examples, device electronic 1500 is also an example of the sending entity 101 and / or the receiving entity 110 in Figure 1.
[102] [102] Controller 1504 is any device, system or part of it that controls at least one operation, such a device can be implemented in hardware, firmware or software, or a combination of at least two of them. For example, controller 1504 may include a hardware processing unit, processing circuit, media encoding and / or decoding hardware and / or software, and / or software program configured to control electronic device operations 1500. For example , controller 1504 processes instructions for software that can be loaded into memory 1506. Controller 1504 may include a number of processors, a multiprocessor core, or some other type of processor, depending on the particular "implementation. In addition, controller 1504 may be implemented using a number of heterogeneous processor systems in which a “primary processor is present with secondary processors on a single chip. As another illustrative example, controller 1504 may include a symmetric multiprocessor system containing multiple processors of the same type.
[103] [103] Memory 1506 and persistent storage 1508 are examples of storage devices 1516. A storage device is any piece of hardware that is capable of storing information, such as, for example, without limitation, data, program code in functional form , and / or other appropriate information either on a temporary basis and / or on a permanent basis. Memory 1506, in these examples, can be, for example, a random access memory or any other suitable volatile or non-volatile storage device. For example, 1508 persistent storage can contain one or more components or devices. Persistent storage 1508 can be a hard disk, a flash memory, an optical disk, or some combination of the above. The media used by the 1508 persistent storage can also be removable. For example, a removable hard drive can be used for 1508 persistent storage.
[104] [104] Communications unit 1510 provides communication with other data processing systems or devices. In these examples, the communications unit 1510 may include a wireless transmitter (cell, WiFi, etc.), receiver, and / or transceiver, a network interface card and / or any other hardware suitable for sending and / or receiving communications to the over a physical or wireless medium. Communications unit 1510 can provide communication through the use of one or both wireless and physical communications links.
[105] [105] Input / output unit 1512 allows data input and output with other devices that can be connected to or a part of the electronic device 1500.
[106] [106] The program code for an operating system, applications, or other programs can be located on 1516 storage devices, which are communicating with controller 1504 through bus system 1502. In some embodiments, the program code is in a functional form in the persistent storage 1508. These instructions can be loaded into memory 1506 for processing by controller 1504. The processes of the different modalities can be executed by controller 1504 using instructions implemented by computer, which can be located in memory
[107] [107] In some embodiments, several functions described above are implemented or supported by a computer program product that is formed from computer-readable program code and that is incorporated in a computer-readable medium. The program code for the computer program product can be located in a functional form on a computer-readable storage device that is selectively removable and can be loaded or transferred to electronic device 1500 for processing by controller 1504. In some embodiments illustrative, the program code can be downloaded over a persistent storage network 1508 from another device or data processing system for use on the electronic device 1500. For example, program code stored on a computer-readable storage medium on a server data processing system it can be downloaded over a network from the server to electronic device 1500. The data processing system providing program code can be a computer server, a client computer, or any other device capable of storing and transmitting the pro code grass.
[108] [108] Although the present invention has been described with an exemplary embodiment, several changes and modifications can be suggested to a person skilled in the art. It is intended that the present description covers these changes and modifications that fall within the scope of the attached claims.

权利要求:
Claims (10)
[1]
1. Method of generating a transport package by a shipping entity, the method CHARACTERIZED by the fact that it comprises: generating a transport package to include a package header, a payload header and a payload, the package header comprising an identifier of a payload type in a field indicating one of a plurality of payload types, the plurality of payload types comprising a first unloading mode payload type and a second payload type a continuous transmission mode; and send the shipping package.
[2]
2. Method according to claim 1, CHARACTERIZED by the fact that the download mode indicates a generic file delivery mode (GFD) for packaging media data based on a size of the payload to be transported; the streaming mode indicates a media processing unit (MPU) mode of packaging media data based on a type of data to be carried in the payload; and the download mode and the continuous transmission mode are used in a single delivery session.
[3]
3. Method according to claim 1, CHARACTERIZED by the fact that the plurality of types of payload still comprise at least one of a third type of payload indicating that the payload comprises a signaling message and a fourth type of payload payload indicating that the payload comprises an early error correction (FEC) repair symbol.
[4]
4. Method, according to claim 1, CHARACTERIZED by the fact that the transport package includes one or more fragments of a media processing unit.
[5]
5. Method according to claim 1, CHARACTERIZED by the fact that if the identifier of a payload type indicates the second payload type of the continuous transmission mode, the payload header comprises a type field indicating a payload data type.
[6]
6. Method, according to claim 5, CHARACTERIZED by the fact that the type field indicates a metadata from a media processing unit, a metadata from a film fragment, and a timed or non-timed media data.
[7]
7. Method according to claim 6, CHARACTERIZED by the fact that the media processing unit metadata comprises a ftyp box including a file type, an mmpu box including a media processing unit configuration, and a moov box including codec configuration information; and the film fragment metadata comprises a moof box including media data header information and a portion of an mdat box.
[8]
8. Device in a shipping entity capable of generating a transport package, the device CHARACTERIZED by the fact that it comprises: processing circuit configured for: generating a transport package to include a package header, a payload header and a payload, the packet header comprising an identifier of a payload type in a field indicating one of a plurality of payload types, and the plurality of payload types comprising a first unloading mode payload type , and a second type of payload in a continuous transmission mode; and a transmitter configured to send the transport package.
[9]
9. Method of processing a transport package by a receiving entity, the method CHARACTERIZED by the fact that it comprises: receiving a transport package to include a package header, a payload header and a payload, the package header comprising an identifier of a payload type in a field indicating one of a plurality of payload types, and the plurality of payload types comprising a first type of unloading mode payload, and a second type of payload useful in a continuous transmission mode; and processing the payload according to the package header and the payload header.
[10]
10. Device in a receiving entity capable of processing a transport package, the device FEATURED by the fact that it comprises: a receiver configured to receive the transport package to include a package header, a payload header and a payload , the packet header comprising an identifier of a payload type in a field indicating one of a plurality of payload types, and the plurality of payload types comprising a first unloading mode payload type, and a second type of payload in a continuous transmission mode; and processing circuit configured to process the payload according to the packet header and the payload header.

类似技术:

---

公开号 | 公开日 | 专利标题

---

BR112016001661A2|2020-08-25|method and apparatus for packet transmission supporting unloading and continuous transmission

---

US20210176506A1|2021-06-10|Apparatus and method for transmitting/receiving processes of a broadcast signal

---

JP6797988B2|2020-12-09|Receiver that receives media packets in a multimedia system

---

JP2017528025A|2017-09-21|Packet transmission / reception apparatus and method in multimedia communication system

---

Paik et al.2018|Media-aware scheduling method for transmitting signalling message over MPEG media transport-based broadcast

---

KR102207453B1|2021-01-25|Method for simplification in configuration of mmt packet and apparatus for the same

同族专利:

---

公开号 | 公开日

---

KR102127733B1|2020-06-30|

---

JP5883199B2|2016-03-09|

---

JP2015530854A|2015-10-15|

---

EP3025464B1|2021-04-21|

---

US20150032845A1|2015-01-29|

---

EP3025464A1|2016-06-01|

---

JP6106775B2|2017-04-05|

---

KR20150015542A|2015-02-10|

---

MY174260A|2020-04-01|

---

AU2014293819B2|2018-05-17|

---

JP2018148577A|2018-09-20|

---

JP2016129358A|2016-07-14|

---

KR20190101351A|2019-08-30|

---

CN110830511B|2021-10-26|

---

MX356847B|2018-06-18|

---

KR102015963B1|2019-08-30|

---

WO2015012645A1|2015-01-29|

---

JP6346329B2|2018-06-20|

---

JP6526289B2|2019-06-05|

---

KR101530825B1|2015-06-29|

---

CN105409174A|2016-03-16|

---

US20200204609A1|2020-06-25|

---

EP3840313A1|2021-06-23|

---

EP3025464A4|2017-01-11|

---

CN111049820A|2020-04-21|

---

JP2017108458A|2017-06-15|

---

ES2878022T3|2021-11-18|

---

MX2016001137A|2016-04-29|

---

AU2014293819A1|2016-02-04|

---

KR20150013081A|2015-02-04|

---

CN110830511A|2020-02-21|

---

CN105409174B|2020-01-03|

引用文献:

---

公开号 | 申请日 | 公开日 | 申请人 | 专利标题

---

---

US6460086B1|1998-12-01|2002-10-01|Sun Microsystems, Inc.|Method and apparatus for delivery of a bytecode embedded within a transport stream|

---

JP4399998B2|2001-03-22|2010-01-20|株式会社日立製作所|How to store digital broadcast streams|

---

KR100565900B1|2003-12-26|2006-03-31|한국전자통신연구원|Apparatus and Method of the broadcasting signal transformation for transforming a digital TV broadcasting signal to a digital radio broadcasting signal|

---

US20050190756A1|2004-02-26|2005-09-01|Mundra Satish Kumar M.|RTP payload for voice band data transmission|

---

WO2006048807A1|2004-11-04|2006-05-11|Koninklijke Philips Electronics N.V.|Method and device for processing coded video data|

---

KR20110022016A|2005-08-02|2011-03-04|엘지전자 주식회사|Digital television transmitter and digital television receiver|

---

KR20080006441A|2006-07-12|2008-01-16|삼성전자주식회사|Apparatus and method for transmitting media data and apparatus and method for receiving media data|

---

US20080040498A1|2006-08-10|2008-02-14|Nokia Corporation|System and method of XML based content fragmentation for rich media streaming|

---

US20080134266A1|2006-11-24|2008-06-05|Young-Seok Kang|Digital broadcasting system and error correction method thereof|

---

US7995590B2|2007-03-27|2011-08-09|Cisco Technology, Inc.|Method and system for communicating H.263 macroblock boundaries using H.221 BAS for RFC2190-compliant fragmentation|

---

US8995422B2|2007-06-21|2015-03-31|Interdigital Technology Corporation|Signaling in a wireless communication system|

---

US8180029B2|2007-06-28|2012-05-15|Voxer Ip Llc|Telecommunication and multimedia management method and apparatus|

---

CN101802823A|2007-08-20|2010-08-11|诺基亚公司|Segmented metadata and indexes for streamed multimedia data|

---

KR101034758B1|2007-10-04|2011-05-17|에스케이 텔레콤주식회사|Method for Providing Initial Behavior of Multimedia Application Format Content and System therefor|

---

KR101653310B1|2009-09-02|2016-09-01|엘지전자 주식회사|Method and Apparatus of transmitting and receiving MAC PDU using a MAC header|

---

KR101216100B1|2009-11-18|2012-12-26|엘지전자 주식회사|Method and Apparatus of transmitting MAC PDU with a Fragmentation and packing Extended Header|

---

EP2418792A1|2010-05-19|2012-02-15|Fraunhofer-Gesellschaft zur Förderung der Angewandten Forschung e.V.|Digital Multimedia Broadcast with efficient transmission of conditional access data in the transport stream packet of the program association table |

---

KR101857416B1|2011-06-13|2018-05-16|한국전자통신연구원|Method of delivering media data based on packet with header minimizing delivery overhead|

---

JP2014521245A|2011-07-08|2014-08-25|サムスンエレクトロニクスカンパニーリミテッド|Method for generating forward error correction packet in multimedia system and method and apparatus for transmitting / receiving error correction packet|

---

KR101933465B1|2011-10-13|2019-01-11|삼성전자주식회사|Apparatus and method for transmitting/receiving a packet in a mobile communication system|

---

KR20130040090A|2011-10-13|2013-04-23|삼성전자주식회사|Apparatus and method for delivering multimedia data in hybrid network|

---

US9319721B2|2011-10-13|2016-04-19|Electronics And Telecommunications Research Institute|Method of configuring and transmitting an MMT transport packet|

---

KR101995221B1|2011-11-24|2019-07-16|삼성전자주식회사|Apparatus and method for transmitting and receiving packet in communication system|

---

US20130136193A1|2011-11-30|2013-05-30|Samsung Electronics Co. Ltd.|Apparatus and method of transmitting/receiving broadcast data|

---

US20140369222A1|2012-01-26|2014-12-18|Electronics And Telecommunications Research Institute|Method for estimating network jitter in apparatus for transmitting coded media data|

---

EP2830318A4|2012-03-23|2015-12-02|Humax Holdings Co Ltd|Hybrid delivery method and reception method for mmt packaged svc video contents|

---

CN108777676B|2012-04-25|2021-01-12|三星电子株式会社|Apparatus and method for receiving media data in multimedia transmission system|

---

US9544641B2|2012-05-10|2017-01-10|Humax Co., Ltd.|Hybrid transmission method through MMT packet format extension|

---

KR20140008237A|2012-07-10|2014-01-21|한국전자통신연구원|Packet transmission and reception apparatus and method in mmt hybrid transmissing service|

---

JP5641090B2|2013-03-14|2014-12-17|ソニー株式会社|Transmitting apparatus, transmitting method, receiving apparatus, and receiving method|

---

CN110418166A|2013-04-30|2019-11-05|索尼公司|Sending device, sending method, receiving device and method of reseptance|

---

US9998773B2|2013-06-07|2018-06-12|Sony Corporation|Transmission device, transmission method of transmission stream, and processing device|

---

JPWO2014196335A1|2013-06-07|2017-02-23|ソニー株式会社|Transmitting apparatus, transmitting method, receiving apparatus, and receiving method|

---

JP6605789B2|2013-06-18|2019-11-13|パナソニックインテレクチュアルプロパティコーポレーションオブアメリカ|Transmission method, reception method, transmission device, and reception device|

---

US20150032845A1|2013-07-26|2015-01-29|Samsung Electronics Co., Ltd.|Packet transmission protocol supporting downloading and streaming|JP2009020203A|2007-07-10|2009-01-29|Ricoh Co Ltd|Optical scanner and image forming apparatus|

---

US20150032845A1|2013-07-26|2015-01-29|Samsung Electronics Co., Ltd.|Packet transmission protocol supporting downloading and streaming|

---

US9807452B2|2013-10-07|2017-10-31|Samsung Electronics Co., Ltd.|Practical delivery of high quality video using dynamic adaptive hypertext transport protocolstreamingwithout using HTTP in a broadcast network|

---

US9641831B2|2013-10-28|2017-05-02|Electronics And Telecommunications Research Institute|Apparatus and method for transmitting/receiving moving picture experts groupmedia transportsignaling message for measurement configurationprocessing|

---

KR20160142327A|2014-04-30|2016-12-12|엘지전자 주식회사|Broadcast transmission apparatus, broadcast reception apparatus, operation method of the broadcast transmission apparatus and operation method of the broadcast reception apparatus|

---

WO2015178690A1|2014-05-21|2015-11-26|엘지전자 주식회사|Broadcast signal transmitting/receiving method and device|

---

CN106416270B|2014-06-10|2020-01-17|索尼公司|Transmission device, transmission method, and reception device|

---

KR102191878B1|2014-07-04|2020-12-16|삼성전자주식회사|Method and apparatus for receiving media packet in a multimedia system|

---

KR102174325B1|2015-02-13|2020-11-04|에스케이텔레콤 주식회사|Computer readable recording medium recorded program for providing content adapted for network, and APPARATUS FOR PROVIDING CONTENT ADAPTED FOR NETWORK|

---

JP6264501B2|2015-03-02|2018-01-24|日本電気株式会社|Decoding device, decoding method, and decoding program|

---

US10721538B2|2015-03-08|2020-07-21|Lg Electronics Inc.|Apparatus and method for transmitting and receiving broadcast signal|

---

JP6543819B2|2015-04-28|2019-07-17|日本放送協会|Processing device and program|

---

KR102209785B1|2015-06-09|2021-01-28|에스케이텔레콤 주식회사|Method for caching processing of mmt packet and apparatus for the same, mthod for generating of mmt packet and apparatus for the same|

---

KR102209784B1|2015-06-09|2021-01-28|에스케이텔레콤 주식회사|Method for caching processing of mmt packet and apparatus for the same, mthod for generating of mmt packet and apparatus for the same|

---

US10750215B2|2015-07-27|2020-08-18|Lg Electronics Inc.|Method and device for transmitting metadata in WFD|

---

US10116576B2|2015-10-19|2018-10-30|Samsung Electronics Co., Ltd.|Methods and apparatus for random access of HEVC bitstream for MMT|

---

WO2017133611A1|2016-02-02|2017-08-10|上海交通大学|Information interaction mechanism and network transmission method in multimedia system|

---

KR20170130253A|2016-05-18|2017-11-28|에스케이텔레콤 주식회사|Method for providing of adaptive streaming service and apparatus therefor|

---

WO2017200319A1|2016-05-18|2017-11-23|에스케이텔레콤 주식회사|Method providing for adaptive streaming service, and device therefor|

---

KR20170133805A|2016-05-26|2017-12-06|삼성전자주식회사|Method and apparatus for transmitting media time information in mmt network system|

---

FR3052943B1|2016-06-15|2018-12-14|Hl2|METHOD FOR RECONSTRUCTING DATA IN LOW-FLOW TRANSMISSION|

---

FR3052944B1|2016-06-15|2019-07-19|Hl2|METHOD FOR SEGMENTING HIGH-PERFORMANCE DATA|

---

CN106411872B|2016-09-21|2019-09-17|杭州迪普科技股份有限公司|A kind of method and apparatus of the message compression based on Packet Classification|

---

US10958988B2|2017-03-24|2021-03-23|Mediatek Inc.|Methods and apparatus for media content asset changes|

---

US10594618B1|2017-06-06|2020-03-17|Juniper Networks, Inc|Apparatus, system, and method for fragmenting packets into segments that comply with the maximum transmission unit of egress interfaces|

---

KR20210021861A|2019-08-19|2021-03-02|제노팜|Use of Interferon-beta mutein Immunocytokines for Treatment of Human Epidermal Growth Factor Receptor 2 Positive Cancer and Methods of Patient Screening|

法律状态:
2018-11-06| B06F| Objections, documents and/or translations needed after an examination request according [chapter 6.6 patent gazette]|

---

2020-08-18| B06U| Preliminary requirement: requests with searches performed by other patent offices: procedure suspended [chapter 6.21 patent gazette]|

---

2020-08-18| B15K| Others concerning applications: alteration of classification|Free format text: A CLASSIFICACAO ANTERIOR ERA: H04L 12/951 Ipc: H04L 29/08 (2006.01) |

---

2021-11-23| B350| Update of information on the portal [chapter 15.35 patent gazette]|

优先权:

---

申请号 | 申请日 | 专利标题

---

US201361859015P| true| 2013-07-26|2013-07-26|

---

US61/859,015|2013-07-26|

---

US201361896570P| true| 2013-10-28|2013-10-28|

---

US61/896,570|2013-10-28|

---

US14/178,212|2014-02-11|

---

US14/178,212|US20150032845A1|2013-07-26|2014-02-11|Packet transmission protocol supporting downloading and streaming|

---

PCT/KR2014/006829|WO2015012645A1|2013-07-26|2014-07-25|Method and apparatus for packet transmission supporting downloading and streaming|

---